doing this directly is probably kinda dangerous, and there's some hidden nuance in this index I think, with rbac and building block alerts and things like that. Probably what should be done is make the session_view dependent on the ruleRegistry plugin, and make use of the AlertsClient exported by that plugin.

Examples of this would be appreciated, not sure how to go about accessing AlertsClient after making rule_registry a dep. I assume it's not as simple as just importing AlertsClient from rule_registry/server/index.ts

@mitodrummer you can use the rule_registry plugin start contract RuleRegistryPluginStartContract for accessing AlertsClient, by calling the method getRacClientWithRequest.
I didn't find the code for AlertsClient , but here is the similar usage of RulesClient: you get it by calling getRulesClientWithRequest, code x-pack/plugins/monitoring/server/plugin.ts

https://github.com/elastic/kibana/blob/main/x-pack/plugins/monitoring/server/plugin.ts#L333-L340

rule_registry is added as a dep and I'm making use of getRacClientWithRequest in alerts_route.ts. Let me know if the plugin setup looks good.

is alerts here in case fetching alerts ran into error? Because I imagine if we don't have alerts, it will just be a truthy []. If it is for errors, would the alertsError be enough for error handling?

It's to avoid passing an undefined to ProcessTree as the prop expects an array.

alerts is initially undefined until the react-query fetch completes.

This test is great, but it tests the function executed inside and it doesn't test the route itself. Please check the examples here.
As the long term vision I suggest to split the routes and its internal logic to the library files or SessionViewClient, if you want to expose this logic not only with the routs.